Application No.: 



10/769.176 



REMARKS 

Claims 1-16 are pending. Claim 9 is amended. Reconsideration is respectfully requested 
based on the arguments below. 

Double Patenting 

Claims 1 and 9 stand rejected on the ground of nonstatutory obviousness-type double 
patenting as being unpatentable over claims 1 and 16 of U.S. Patent No. 7,356,347 Bl. 
Applicant is submitting a terminal disclaimer to obviate this rejection. Accordingly, Applicant 
respectfully requests withdrawal of this rejection. 

Claim Objections 

Claim 9 is objected to because of a typographical error. Applicant amends claim 9 to 
obviate this objection. Accordingly, Applicant respectfully requests withdrawal of this 
objection. 

35 U.S.C. § 103 Rejections 

Claims 1-16 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Lunsford 
et al. (U.S. Patent No. 6,982,962 Bl) in view of Phillips (U.S. Patent No. 7,748,195 Bl). 
Applicant respectfully traverses this rejection. 

Lunsford and Phillips, alone or in combination, do not teach or suggest the every element 
of the claims. Lunsford is directed towards selecting a network access provider using a personal 
information device wherein the user's preferences are considered in such selection. See 
Lunsford, Abstract. Nothing in Lunsford teaches or suggests enabling legacy applications access 
to anything, including network access providers, much less access of legacy applications to a 
Bluetooth standard. 

With regard to the claim limitations that include executing a legacy application, the 
examiner cites 

A unit that wants to discover other Bluetooth units enters an inquiry 
substate. In this substate, it continuously transmits the inquiry message (which is 
an ID packet) at different hop frequencies. A unit that allows itself to be 
discovered, regularly enters the inquiry scan substate to respond to inquiry 
messages. 
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FIG. 3 is a protocol diagram 200 illustrating the layers of the Bluetooth 
(RF) protocol stack 150 that may be used in a preferred embodiment of the 
present invention. An RF protocol stack is implemented at each of the connection 
endpoints of an RF link. For example, a PID 10 and network access providers or 
devices as shown in FIG. 1, could each implement an RF stack to enable a link. 
The required layers of the RF link using the Bluetooth system are the Baseband 
layer 210, the Link Manager Protocol layer (LMP) 220, the Logical Link Control 
and Adaptation Protocol (L2CAP) layer 230, Telephony Control Protocol (TCS) 
layer 240, RFCOMM layer 250, Service Discovery Protocol layer 260 and Object 
Exchange Protocol (OBEX) layer 270. 

FIG. 4 is a protocol diagram 280, illustrating the layers of the IrDA 
protocol stack 120 shown in FIG. 2. For example, the PID 10 and the cellular 
telephone 12 each implement an IiDA protocol stack to enable the link 15. 

The required layers of an IrDA protocol stack 120 are the physical layers 
282, the IrLAP layer 284, the IrLMP layer 286 and the IAS layer 290. The 
physical layer 282 specifies optical characteristics of the link, encoding of the 
data, and framing for various speeds. The IrLAP (Link Access Protocol) layer 284 
establishes the basic reliable connection between the two ends of the link. The 
IrLMP (Link Management Protocol) layer 286 multiplexes services and 
applications on the IrLAP connection. The IAS (Information Access Service) 
layer 290 provides a directory of services on an IrDA device. 

The IrDA protocol also specifies a number of optional protocol layers, 
these protocol layers being Tiny TP 288, IrOBEX 294, IrCOMM 296 and IrLAN 
292. Tiny TP (Tiny Transport Protocol) 288 adds per-channel flow control to 
keep traffic over the IrDA link moving smoothly. IrOBEX (Infrared Object 
Exchange Protocol) 294 provides for the easy transfer of files and other data 
objects between the IrDA devices at each end of the link. IrCOMM 296 is a serial 
and parallel port emulation that enables existing applications that use serial and 
parallel communications to use IrDA without change. IrLAN (Infrared Local Area 
Network) 292 enables walk-up infrared LAN access for laptops and other devices. 
The use of the optional layers depends upon the particular application in the IrDA 
device. 

FIG. 6 illustrates the process 330 to evaluate the access providers against a 
user's preferences for an optimum connection to a network access provider. The 
process 330 begins at step 410. The user inputs preferences or criteria that the PID 
processes to determine the optimum network access provider for the particular 
user, per step 420. The preferences include, but are not limited to, security, 
reliability of access, signal level, cost and ownership. The user additionally rates 
the importance of the preferences at step 430. For each preference, the user may, 
in a user interface implementation, configure a slider, for example, to indicate 
how important a particular preference is to the user. This assigned importance 
level is analogous to a weight and may be stored as a value between 0 and 1 and is 
referred to as the weight for the preference W.sub.p. For preferences that cannot 
be normalized, for example, the criterion of cost that cannot be assured to fall 
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within a certain range, the user inputs limit conditions. Thus, a minimum and 
maximum limit value can be used to define a normalization range. For example, 
the most amount the user is willing to pay per minute for Internet access. 

At step 440, each preference or criteria has an associated heuristic routine 
or application as referred to in FIG. 2, which is a function for evaluating the 
preference and referred to as h.sub.p( ) for each preference p. The heuristic 
application makes any measurements necessary to perform the evaluation. Col. 5, 
line 45 - col. 6, line 25; col. 7, lines 15 - 39. 

The citation discusses a Bluetooth protocol stack, layers of an IrDA protocol stack (some that are 
required and some that are optional), and a process to evaluate access providers again a user's 
preferences for an optimum connection to a network access provider. 

The present invention as claimed is specifically directed towards "providing service 
record information (in particular, the service name) for legacy applications on Bluetooth-enabled 
devices." Specification, p. 8, lines 3-4. The applicant identifies this is needed in the art because 
the "Bluetooth specification defines most of the values in [a] service record 50 for a legacy 
application, with the notable exception of the service name (ServiceName). Other than the 
reference to 'some helper application,' the Bluetooth specification provides no guidance 
regarding how the service name for the legacy application is to be provided for service record 
50." Specification, p. 6, lines 10 - 14. As stated by the examiner Lunsford does not contemplate 
these limitations as claimed. 

Phillips is cited to fill this gap, specifically the Service Discovery Protocol and Bluetooth 
registration process. See Phillips as cited by the examiner, col. 5, lines 1-29; col. 6, lines 3-20; 
col. 3, lines 40-66; col. 4, lines 5-67; col. 5, lines 4-67; col. 6, lines 7-67; col. 7, lines 12-64; col. 
9, lines 6-67. Other than describing how the Bluetooth specification connects with other devices 
(which is also described within the applicant's specification), the examiner's citations do not 
teach or suggest the claim limitations. The discussion of Bluetooth and its operation is tangential 
to Phillips purpose, that is, the use of profiles to change the operational behavior of a wireless 
device. Contrary to the examiner's citations and statement that "the service name is provided by 
a virtual serial port driver," nowhere in Phillips are virtual serial ports or legacy applications 
discussed. Moreover, by the use of the word "could" in the statement "the service name could be 
registered in the service record" reveals that the examiner is inappropriately using the applicant's 
specification to meet the prima facie case of obviousness. 
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Nothing in the combination of Lunsford or Phillips's disclosure is directed towards 
enabling a legacy application to communicate using virtual serial ports as claimed. Lunsford is 
directed towards selecting network access using a user's preferences. Phillips is directed towards 
using profiles to change the operational behavior of a wireless device. Though each reference 
mentions the Bluetooth specification, neither reference teaches or suggests enabling a legacy 
application to participate in the Bluetooth service discovery process. Any such teaching is solely 
derived from the applicant's disclosure and nothing contain in the cited references. Accordingly, 
Applicant respectfully requests withdrawal of this rejection. 



All of the stated grounds of rejection have been properly traversed, accommodated, or 
rendered moot. Applicant therefore respectfully requests that the Examiner reconsider all 
presently outstanding rejections, and that they be withdrawn. The Examiner is invited to 
telephone the undersigned representative if an interview might expedite allowance of this 
application. 



Conclusion 



Respectfully submitted, 
BERRY & ASSOCIATES P.C. 



Dated: May 17, 2010 



By: /shawn diedtrich/ 
Reena Kuyper 
Registration No. 58,176 



9229 Sunset Blvd., Suite 630 
Los Angeles, CA 90069 
(310) 247-2860 
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